docs/Developer-Guide_Extensions-List.md (2)

301-304: Consider using an admonition for the non-working kernel warning.

The warning about nomod producing a non-working kernel is important. Using MkDocs admonition syntax would make it more visually prominent:

📝 Suggested enhancement

 ## nomod
 
-Builds the kernel with all modules disabled (`localmodconfig` with empty lsmod). Produces a non-working kernel — intended for rapid kernel build/packaging tests only.
+Builds the kernel with all modules disabled (`localmodconfig` with empty lsmod).
+
+!!! warning
+    Produces a non-working kernel — intended for rapid kernel build/packaging tests only.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/Developer-Guide_Extensions-List.md` around lines 301 - 304, Replace the
plain-text warning under the "## nomod" section with an MkDocs admonition so the
"non-working kernel" note is visually prominent; locate the "## nomod" heading
and its description and wrap the sentence "Produces a non-working kernel —
intended for rapid kernel build/packaging tests only." inside an admonition
block (e.g., note/warning/danger) using MkDocs admonition syntax so readers
immediately see the caveat.

---

379-382: Consider adding a link to Debian Trixie documentation or release notes.

The UFS extension specifies a build host requirement (Debian Trixie 13+) that users may need guidance on. Consider linking to relevant Debian or Docker documentation for users unfamiliar with setting up a Trixie-based build environment.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/Developer-Guide_Extensions-List.md` around lines 379 - 382, The "ufs"
extension docs mention Debian Trixie and setting DOCKER_ARMBIAN_BASE_IMAGE but
lack links; update the "ufs" section to include one or two authoritative links
(e.g., Debian Trixie release/notes and Docker image reference) so users can find
release details and how to use debian:trixie as a base image; specifically
modify the "ufs" header/paragraph to append links to the Debian Trixie release
notes and the Docker Hub debian image (or Debian documentation) and optionally a
short hint about setting DOCKER_ARMBIAN_BASE_IMAGE to debian:trixie.

docs/Developer-Guide_Extensions-List.md (2)

17-429: Consider adding a mini index for faster navigation.

For a 60+ entry page, an A–Z jump list or compact table at the top would improve scanability.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/Developer-Guide_Extensions-List.md` around lines 17 - 429, Add a compact
A–Z mini index at the top of the Extensions list that links to each extension
section (the "## <extension-name>" headings like "## allwinner-kernel-bump", "##
amlogic-fip-blobs", etc.). Create a short alphabet jump row (A B C ... Z)
followed by an alphabetical list of anchor links to each "##" section (or
grouped by initial letter) so readers can click to jump; ensure anchors match
the rendered Markdown heading slugs. Insert this new "Mini index" block
immediately after the main title/intro to improve navigation.

---

3-13: Reduce future drift for this manually curated list.

Because this page is long and extension inventory changes over time, consider adding a short “source of truth / last generated from” note (or linking a generation script) to keep this list synchronized with extensions/.

Also applies to: 17-429

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/Developer-Guide_Extensions-List.md` around lines 3 - 13, Add a “source
of truth / last generated from” note to Developer-Guide_Extensions-List.md so
readers know where this manually curated inventory comes from and when it was
last updated; explicitly state that the list is generated from the extensions/
directory and include a timestamp plus a link to the generation script (e.g., a
script that scans extensions/ and emits this markdown) or the path to that
generator, and if no generator exists add a small script
(generate-extensions-list) and reference it in the note so future updates can be
automated and the file kept in sync.

docs/Developer-Guide_Extensions-List.md (1)

1-14: Add a refresh/provenance note to reduce future drift.

This page is likely to go stale unless maintainers can quickly regenerate/verify it. Please add one short line describing source-of-truth + refresh workflow (script/command + optional “last refreshed” date).

I can draft a tiny “How to refresh this list” section if you want.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/Developer-Guide_Extensions-List.md` around lines 1 - 14, Add a short
provenance/refresh note to the "Extensions Reference" page stating the
source-of-truth (the extensions/ directory in the build repo) and the refresh
workflow: the command or script to regenerate the list (e.g., a one-liner that
scans extensions/ or the exact ./compile.sh invocation used for testing), plus
an optional "Last refreshed: YYYY-MM-DD" field; place this single-line note near
the top under the heading or at the end of the intro so maintainers can quickly
run the command and update the date when validating the list.

docs/Developer-Guide_Extensions-List.md (1)

3-5: Add a source snapshot marker to reduce drift risk.

Since this list is maintained manually from another repo, add a “last verified against build repo commit/date” line near the top for traceability.

Proposed doc tweak

 Alphabetical reference of all official Armbian build framework extensions.
 Extensions live in the `extensions/` directory of the build repository.
+Last verified against: `armbian/build@<commit>` on `<YYYY-MM-DD>`.
 
 To enable one or more extensions:

Also applies to: 12-14

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/Developer-Guide_Extensions-List.md` around lines 3 - 5, Add a “last
verified against build repo commit/date” marker near the top of
Developer-Guide_Extensions-List.md to record the commit SHA and verification
date used to generate the manual list; update the document header (the lines
describing the alphabetical reference and extensions directory) to include a
single-line marker like “Last verified against build repo: <commit-sha> on
<YYYY-MM-DD>” and ensure this line is updated whenever the list is regenerated
to reduce drift and improve traceability.

docs/Developer-Guide_Extension-kernel-rust.md (1)

49-53: Direct users to the Rust-for-Linux policy instead of hardcoding rustc versions.

Line 49 hardcodes rustc ≥ 1.78, which will need updating as upstream requirements change (they already differ between kernel releases: 6.10 requires pinned toolchains, while 6.11–6.12 use MSRV 1.78.0). The Rust-for-Linux project maintains a documented version policy for this. Reword as "current baseline" and point users to the policy:

Suggested change

-- **Kernel version**: 6.12 or newer (requires rustc ≥ 1.78).
+- **Kernel version (current baseline)**: 6.12 or newer.
+  Minimum `rustc` can change by kernel release; verify against the Rust-for-Linux version policy.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/Developer-Guide_Extension-kernel-rust.md` around lines 49 - 53, Replace
the hardcoded "rustc ≥ 1.78" text in Developer-Guide_Extension-kernel-rust.md
(the "Kernel version" bullet) with a phrasing that defers to the Rust-for-Linux
version policy—e.g. say "use the current baseline rustc as specified by the
Rust-for-Linux version policy"—and add a brief pointer to the Rust-for-Linux
version policy page so maintainers/users follow upstream requirements instead of
a pinned MSRV; specifically update the line containing "rustc ≥ 1.78" to
reference the policy rather than a concrete version.

docs/Developer-Guide_Extensions-List.md (1)

3-13: Add a sync/provenance note for this catalog.

This page presents itself as the full official list, but it does not say which armbian/build revision it was synced against. A short note like “validated against armbian/build@<sha/date>” would make future drift much easier to spot without changing the current manual workflow.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@docs/Developer-Guide_Extensions-List.md` around lines 3 - 13, Add a short
provenance note to the top of the document indicating which armbian/build
revision the catalog was validated against (for example: "Validated against
armbian/build@<sha> on <date>"). Insert this immediately below the opening line
"Alphabetical reference of all official Armbian build framework extensions." so
it’s obvious when the page is updated; use a clear, consistent format (sha and
ISO date) and include a placeholder for future updates so maintainers can
replace it with the exact commit SHA and date.